A means of XML data storage, e.g. an XML database, usually offers some security mechanisms to define and enforce access to its data which is based on the XML data structure. The assignee of the instant invention, for example, uses XPath expressions to define access permissions based on the XML structure of the data stored in its webMethods Tamino XML Server product. In this regard, security may be defined via configurations including sets of users/groups and access rules to the XML structure via XPath expressions.
When allowing access to the XML data via web services, basic means of access can be created automatically from the XML schema definitions. Tamino does so by offering CRUD service generation, where CRUD is an acronym for Create, Read, Update, and Delete. Services created therewith allow the respective operations upon the XML data corresponding to the schema. More particularly, the Tamino XML Server provides an XML database and a mechanism to create CRUD web services based on XML Schema definitions, while the assignee's Web Service Stack provides a web service runtime environment for deploying the created CRUD web service. The structure-based access control to the data is available in Tamino, and WSDL files are automatically generated by Tamino and deployed into the web service runtime environment.
In the realm of web services, many technologies are available to restrict access to services and operations defined therein to certain users. For instance, web service runtime environments typically provide means to enforce access restrictions to the web services deployed on them, oftentimes using standardized mechanisms such as XACML or WS-Policy, Unfortunately, however, restrictions defined at the data level are believed to apply only at the time when the data is actually accessed. That is, if a user employs an operation in a web service that tries to do something with the data for which the user has no permission, the service layer has no knowledge of the attempted operation, unless it has been told about it by other means. Only at the moment that data access is actually attempted will an error be generated, and only then will the service be obliged to handle the error in some way and inform the user or caller, accordingly.
Moreover, security policies implemented using standardized mechanisms like XACML or WS-Policy typically have to be configured in the web service runtime environment and are not dynamically generated based on existing security definitions on the accessed data structures. And while there are some available solutions that involve automatic generation of web services based on data structure definitions, no existing solution is believed to focus on deriving runtime security definitions based in data structure security definitions and no existing solution is believed to focus on dynamic WSDL generation based on the security definitions of the data structure. For instance, currently available ideas and concepts that dynamically add security considerations to WSDL files do that in respect to general security aspects and do not generate WSDL files that contain security information specific to a certain caller based on access permissions in the underlying backend system as described below in connection with certain example embodiments.
Thus, it will be appreciated that there is a need in the art for techniques that allow data access requests to be handled, for security purposes, in the “higher” web service layer.
One aspect of certain example embodiments relates to a unique approach to deriving permissions to access web services depending on the permissions for access granted at the database, rather than relying only on the access control done at the web service layer.
Another aspect of certain example embodiments relates to a two-level security system, where the higher level security features are automatically derived from the underlying database. This may, in certain example instances, advantageously result in easier setup, e.g., if proper access rights are set within the database.
Another aspect of certain example embodiments relates to techniques for deriving security settings that are defined on an XML data structure level for possible handling at the web service layer. In certain example embodiments where data access requests that are forbidden according to the data layer can be dealt with accordingly in the “higher” web service layer, the overall system advantageously may become more robust, e.g., in the sense that these accesses can be refused earlier and more cleanly (e.g., without having to process the request at the higher layer(s) and subsequently pass it to the lower layer(s) where it will be prohibited). Another advantage relates to enhanced usability, as the system's web service interface becomes clearer and more efficient when only the access means that are permitted for a certain caller are presented.
In certain example embodiments, a computer system is provided. A web service runtime engine thereof includes a plurality of web services configured to perform operations in connection with XML data, and a web service runtime access enforcement module. An XML server thereof includes a non-transitory XML data storage area tangibly storing the XML data; a non-transitory XML schema storage area tangibly storing a plurality of XML schemas that describe the XML data; and a non-transitory access control list (ACL) storage area tangibly storing XML structure-based ACLs, defining whether and (if possible) how clients and/or web services can access the XML data. The web service runtime access enforcement module is configured to determine, at the web service runtime engine, whether a given web service initiated by or on behalf of a user using a client computer can perform one or more requested operations on the XML data, based on a corresponding XML structure-based ACL stored in the non-transitory ACL storage area.
For instance, according to certain example embodiments, the web service runtime access enforcement module may be configured to selectively either (a) prevent the one or more requested operations of the given web service and cause an error to be returned to the client, or (b) allow the one or more requested operations of the given web service and cause their results, if any, to be returned to the client, in dependence on the determination.
According to certain example embodiments, the system may further include an XACML enforcement component and an XACML generator, located within the web service runtime access enforcement component of the web service runtime engine, that are configured to cooperate with one another to enable access control policies to be set using action, target, and subject attributes.
In certain example embodiments, there is provided an access control method for use in a computer system including a plurality of client computers operated by respective users, an XML server, and a web service runtime engine interposed between the client computers and the XML server. A call for a web service operation is received, from a client computer and at the web service runtime engine. XML data objects from a database of XML data objects located on the XML server implicated by the web service operation that has been called are identified, with the XML data objects having corresponding XML data structures. Access permissions for the user for the identified XML data objects are retrieved from an access permission store on the XML server, with the access permissions in the access permission store being generated automatically from XML data structures for corresponding XML data objects. It is determined, at the web service runtime engine and based on the retrieved access permissions, whether the called web service operation can be performed on behalf of the user. Based on the determination, the called web service operation is either permitted or prohibited.
According to certain example embodiments, a web service response may be returned to the client following the permitting or prohibiting.
In certain example embodiments, there is provided a web service access control method for use in a computer system including a plurality of client computers operated by respective users, an XML server storing XML documents in a storage location thereon, and a web service runtime engine interposed between the client computers and the XML server. A request for a user-specific WSDL from a given client computer is received at the web service runtime engine. A listing of all web service calls possible for the given client computer is retrieved from a store of generic WSDL files storing all possible web service calls for all client computers and all users. The store of generic WSDL files is located on the XML server. A root element of the affected XML documents is identified for each web service call possible for the given client computer. XML schemas associated with the identified root element(s) are obtained from the XML server. XML documents associated with the obtained XML schemas are determined. Access permissions for the user for the identified XML documents are derived from an access permission store on the XML server, with the access permissions in the access permission store being generated in dependence on structures associated with the XML documents. The user-specific WSDL is generated from the derived access permissions such that the user-specific WSDL includes operations where the required access to the XML documents is granted for the respective user. The user-specific WSDL is returned to the client.
According to certain example embodiments, each said client may be configured to control access to web services in dependence on a user-specific WSDL with its respective user.
According to certain example embodiments, the generic WSDL files may include extensions added by a web service generator during web service creation, the extensions potentially being indicative of which XML data can be accessed in which manner by an associated web service call. For instance, the extensions may be CRUD-type extensions.
In certain example embodiments, non-transitory computer readable storage media tangibly storing instructions that, when executed by at least one processor of a computer, may perform one of these and/or other methods.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.